fix(bridge-node): adopt a factory reset's own renumbering instead of alarming forever (#140) - #151

…alarming forever (#140)

Two deliberate designs collided: a preserving factory reset kept the
endpoint map specifically to REPORT the renumbering the reset causes,
and its log line told the user to clear the report with the §3.11
rebuild — which the plugin's M11 gate correctly refuses on a healthy
node. Permanent alarm, locked door. Live on jarvis at every attach
(indigo-459564566: expected 5, got 2).

Fix is issue option (3), node-side only. Both reset sites — §3.10
factory_reset preserveEndpointNumbers:true and the last-fabric
self-reset — now void every map entry's number (numberVoid: true);
check() silently adopts the next live number for a void entry and
clears the marker (even when the numbers happen to match: the marker is
what must stop being true). Safe by construction: matter.js is always
the allocator (the map is witness-only, even on restore) and both reset
sites are reached with an empty fabric set, so no paired ecosystem
exists that could hold the old numbers. A never-voided entry still
drifts exactly as before — on a >=0.8.0 node surviving drift is a
STRONGER signal, and the plugin's drift error now says so, naming the
bridge-node version rather than the plugin's (adoption is node-side; a
new plugin driving an old node still gets reset drift, and claiming it
away would be #132 again).

Schema stays v2: every reader takes fields by name, so an old build
never looks at the new key — a version bump would guard nothing.

No wire change; golden frames untouched. NOT in this PR, by the #141
precedent (never pin an unpublished version): the bridge-node
0.7.0->0.8.0 bump + npm publish + DEFAULT_INSTALL_SPEC pin, which is
what actually ships the behaviour to installs.

Mutation-verified: adopt-regardless-of-marker fails the
non-void-still-drifts test; skipping voidNumbers at noteLastFabricGone
fails its test. The reset's duplicate-number fingerprint heals under
adoption (tested).

Suites: 2265 Python (+1), 396 TS (+13). Version 2026.8.8 -> 2026.8.9.

Closes #140

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Unpt5UPRdLoZkahH6a4gL

… a void baseline (#140)

The review pass found the two claims-around-the-mechanism defects:

- factoryReset discarded voidNumbers()'s return and unconditionally
  logged "…numbers are now VOID… §3.11 rebuild is not needed" — over a
  write that may have failed, leaving RAM-only markers that a restart
  loses, bringing #140's forever-drift back after the user was told
  otherwise. Same bug class the same function fixed for discard().
  Both call sites now capture the result and branch the log; the
  empty-map no-op (also false) is resolved by gating on size > 0 —
  nothing to void is not a failure, and a bridge that never exported
  gets neither line. persist() already leaves #dirty set, so the retry
  is automatic and the failure line says so.

- voidNumbers left #checked true, so between the reset and the first
  reconcile StatusReport claimed driftChecked: true ("checked, nothing
  moved" per §4.3) over a baseline the node itself just declared void —
  the exact over-claim the #dirty doc comment exists to prevent. Every
  sibling baseline-invalidating op recomputes it; now this one does
  too, and the plugin's "not checked yet" note becomes the honest
  post-reset rendering.

Also: class comment bounds the marker's lifetime honestly (only LIVE
entries adopt; a device offline through the first reconcile keeps its
marker until it next exports — still safe, the argument anchors on "no
fabric survived the reset", not "at the moment of adoption");
BRIDGE_PROTOCOL's three #140 passages now say "since bridge-node
0.8.0" per the doc's own convention, matching the plugin's message.

Three new tests (399 TS): checked-drops-on-void,
void-write-failure-reports-not-a-no-op, and the factoryReset
truth-telling branch under the suite's chmod fault-injection pattern.
Mutation-verified both important fixes fail-before/pass-after.

Suites: 2265 Python, 399 TS.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Unpt5UPRdLoZkahH6a4gL